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1. 


ABSTRACT 


This  documeni  is  lo  serve  the  CDRL  A004  and  A009  requirements  of  a  final  report  for  the  UUVSP 
program. 

The  Objectives  of  the  Unmanned  Undersea  Vehicle  (UUV)  program  was  to  provide  High  Performance 
Scaleable  Computing  (HPSC)  technology  developed  at  Lockheed  Martin  in  a  scaleable  24  GFLOP  HPSC 
processor  for  21  inch  UUV  applications.  The  demonstration  platform  was  to  extend  prior  work  that  was 
done  under  Martin  Labs  (now  integrated  with  Lockheed  Sanders)  for  NUWC  (the  DAP  system)  by 
integrating  HPSC  technology  to  transform  the  DAP  system  into  a  real  time  embedded  system  suitable  for 
UUVSP  applications. 

It  was  decided  that  Naval  Undersea  Warfare  Center  (NUWC)  would  provide  bottom-mapping  algorithms 
for  this  demonstration.  This  algorithm  was  known  as  the  Bathymetric  Algorithm.  This  algorithm  was 
provided  to  Sanders  as  a  C  program  that  ran  on  a  UNIX  workstation.  Sanders  was  responsible  for  tailoring 
this  algorithm  into  a  scaleable  process.  The  algorithm  was  tailored  to  use  the  Wideband  Computers  Inc. 
ADSP-21K  Optimized  DSP  Library,  and  technology  developed  under  the  HPSC  program  for  moving 
information  between  processing  resources. 

2.  HARDWARE  DEVELOPMENT 

2J _ SYSTEM  DIAGRAMS 

The  system  was  to  be  a  demonstration  system  of  embedded  HPSC  technology  for  UUVSP 
applications.  The  first  phase  of  the  “proof  of  concept”  to  extend  HPSC  technology  into  the  UUVSP 
application  arena,  was  to  process  “DAP  data”  in  real  time  in  a  24  GFLOP  HPSC  system.  The  24  GFLOP 
system  was  to  be  formed  factored  into  a  representative  UUVSP  system.  DAP  data  consists  of  previously 
captured  digitized  data  from  an  HRA  system. 


2.1.1  ELECTRICAL  FUNCTIONAL 

SYSTEM  BLOCK  DIAGRAM 
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2,1 .1.1  SYSTEM  OPERATIONAL  MODE 


2.1. 1.1.1  SUMMARY 

Lockheed  Sanders  was  to  develop  the  hardware  listed  above  in  figure  2.1.1.  The  equipment  that 
Lockheed  Sander’s  was  task  to  develop  is  labeled  as  “SANDERS'".  The  Sander’s  developed 
hardware  was  to  demonstrate  an  embedded  24  GFLOPS  system. 

The  Sander’s  hardware  was  to  be  integrated  with  “COTS”  hardware  that  would  have  provided  for 
data  injection  of  DAP  data  into  the  embedded  24  GFLOP  system.  The  injected  data  would  be 
distributed  to  the  APU  modules  which  would  provide  data  processing  on  the  DAP  data.  The 
resultant  data  would  be  sent  back  to  the  COTS  hardware  platform  to  verify  the  processing  results. 

2.1. 1.1 .2  APU  MODULES 

The  APU  modules  were  a  thermally  core  processing  module  consisting  of  16  ADSP'21060,  40 
MHz  floating  point  DSPs.  Each  module  was  capable  of  2  GFLOPS  processing.  Each  module 
consumed  on  average  about  25  watts  of  power  (@3.3  VDC)  and  provided  1280  Mbytes  /  Sec 
communication  transfer  to  the  UUVSP  back  plane. 

The  modules  are  thermally  and  physically  capable  of  scaling  to  a  4  GFLOP  module  utilizing  Quad 
SHARC  MCMs  built  by  Analog  Devices.  It  was  intent  of  the  program  that  if  early  success  and 
funding  allowed,  a  MCM  version  of  the  APU  modules  would  have  be  built  and  demonstrated  in 
the  system. 

2.1. 1.1 .3  DACU  UNITS 

DACU  units  (Digitizing  Analog  Control  Units)  were  not  to  be  developed  in  this  phase  of  the 
UUVSP  program.  The  DACU  units  would  be  responsible  for  interfacing  to  the  HRA  unit, 
digitizing  the  data,  formatting  the  data,  and  passing  the  data  to  the  APU  units  for  processing.  This 
phase  of  the  program  was  to  size  the  DACU  modules,  provide  resources  in  the  system  to  allow  for 
future  development  and  insertion  of  the  units.  The  DACU  units  would  be  necessary  to  achieve  an 
integrated  real  time  system  with  the  HRA. 

2.1 .1.1 .4  BACK  PLANE 

The  UUVSP  back  plane  provided  for  32  module  slots.  16  module  slots  were  dedicated  for  APU 
module  units.  16  module  slots  were  dedicated  for  DACU  module  units.  The  UUVSP  back  plane 
was  an  active  back  plane  based  on  Myrinet  XBAR-S  Port  switch  technology. 

2.1.1 .1.5  POWER  CONVERSION 

The  power  conversion  section  was  responsible  for  generating  the  local  DC  voltage  needed  by  the 
local  electronics  in  the  UUVSP  shell.  It  generated  local  +5.0  VDC,  +3.3VDC,  and  +1.2  VDC. 
The  power  conversion  section  was  used  to  convert  the  local  DC  electronic  voltages  needed  from  a 
tethered  +300  VDC.  The  program  used  COTS  DC-DC  modules  for  this  function. 

The  power  conversion  unit  also  allocated  necessary  resources  for  the  integration  of  the  DACU 
modules  and  the  HRA  front  end.  Both  thermals,  electrical  and  physical  allocation  was  set  aside 
for  this  additional  functionality. 

2.1 .1.1 .6  BUFFER  INTERFACE 

The  buffer  interface  PWB  was  used  to  isolate  signals  between  the  monitor  box  unit  and  the 
UUVSP  shell  unit.  The  UUVSP  shell  electronics  (APU,  DACU,  and  HRA  units)  are  at  a  floating 
ground  potential  to  the  monitor  box  unit  by  design.  The  buffer  card  served  as  a  low  cost  interface 
to  prevent  damage  that  might  have  resulted  from  the  floating  ground  configuration. 
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2.1 .1.1 .7 


MONITOR  BOX. 

The  monitor  box  unit  provided  for  +300  VDC  power  generation  to  the  UUVSP  shell.  The  monitor 
box  also  provided  for  controlled  power  on  /  off  stale  flow,  status  indicators,  and  simple  monitoring 
of  system  health  associated  with  power,  temperature,  and  leak  detection. 

2,2  MODULE  DIAGRAM 
2.2.1  APU  MODULES 


l«P 

1.INK 

IHIKT 


CARD  FRONT 


BACK  PLANE 


Rle=  apu^Wk.ppt 


XBAR  8:  •  Myrin«t  Porls.  L;*h«led  Portll,..  Port  7  (Some  ports  ar«  N.C.I 


2.2-1 .1  MODULE  DESCRIPTION 

Each  APU  module  consisted  of  16  ADSP21060  DSP  arrange  in  clusters  of  4  DSPs  per  node. 
There  are  4  processing  clusters  per  each  APU  module.  Each  processing  cluster  or  node  connects 
to  32  Mbytes  of  shared  synchronous  DRAM  (SDRAM)  with  a  shared  LANai  interface.  The 
LANai,  SDRAM  and  DSPs  interfaces  via  the  ADSP21060  data  bus  that  operates  at  40  MHz,  32 
bits  wide,  yielding  a  bus  data  rate  of  160  Mbytes  /  sec.  Each  DSP  runs  at  40  MHz,  at  +3.3  VDC 
operations,  and  with  a  peak  performance  of  120  MFLOPS  per  second.  The  LANai  operates  at  40 
MHz,  providing  an  interface  to  the  back  plane  Myrinet  network.  The  LANai  interfaces  to  the  back 
plane  network  with  a  data  transfer  rate  of  160  Mbytes  /  Sec.  Each  module  has  4  Myrinet  LAN 
connections  to  the  back  plane,  providing  for  a  total  back  plane  interface  bandwidth  of  1280 
Mbytes  /  sec  per  APU  module. 
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2,2.2  BACK  PLANE  MODULE 


2.2.2.1  MODULE  DESCRIPTION 

The  UUVSP  back  plane  unit  was  an  active  back  plane  system  based  on  Myricoms  XBAR-8  ICs. 
Seven  XBAR-8  were  used  to  construct  a  Myrinet  network  to  provide  back  plane  connectivity  for 
the  APU  and  DACU  modules  (16+16=32)  in  the  system.  The  configuration  constructed  is  shown 
in  the  above  diagram.  Each  port  has  a  data  communication  bandwidth  of  1 60  Mbytes  /  Sec.  For 
the  system  as  a  whole,  the  aggregate  possible  simultaneous  inter  node  bandwidth  that  could  be 
achieve  is  10,240  Mbytes  /  Sec  (10.240  Gbytes/Sec). 

A  single  25M-1M  Myrinet  protocol  conversion  IC  was  used  to  interface  the  SUN  development 
platform  to  the  UUVSP  system  via  the  Myrinet  protocol.  The  data  bandwidth  of  this  link  is  at  160 
Mbytes  /  Sec. 

2J _ MECHANICAL  DIAGRAMS 

2.3.1  UUVSP  LAYOUT  FIGURE 
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2.3,2  SUMMARY 


The  form  factor  of  the  UUVSP  developmental  system  consisted  of  government  supplied  cylinder 
shells  used  to  house  the  electronic  components.  The  shells  are  approximately  21  inches  in 
diameter. 

2.3.2.1  FRONT 

The  front  shell  was  the  HRA  component.  This  section  was  the  sole  responsibility  of  NUWC.  This 
shell  section  would  not  have  been  interface  to  under  the  first  phase  of  the  developmental  program. 
However,  work  done  in  the  first  phase  of  the  program  have  allocated  necessary  design  and 
resource  functionality  to  allow  for  the  integration  of  this  section  without  modification  of  prior 
work. 

2.3.2.2  MID 

The  mid  section  contained  the  electronic  processing  modules  (APUs),  the  DACUs,  and  the  back 
plane  unit.  This  section  was  design  to  hold  1 6  APU  units,  1 6  DACU  units,  and  1  back  plane  unit. 
This  section  also  allowed  for  a  power  cabling  harness  to  be  routed  from  the  power  section  shell 
(rear)  to  the  HRA  unit  (front). 

2.3.2.3  REAR 

The  rear  section  contained  the  power  conversion  units  (DC>DC  con\  erter  modules)  and  the  buffer 
interface  circuit  card.  All  the  necessary  I/O  for  a  tethered  system  would  interface  to  this  shell 
section  using  the  buffer  interface  circuit  card. 

2.3.3  EXPLODED  MID  SECTION  VIEW 


Processor  Shell  Exploded  View 
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2.4. 


HARDWARE  MODULE  STATUS 


2.4.1  APU  MODULES 

2.4.1.1  BUILT 

13  APU  modules  were  built  and  successfully  tested  at  a  bench  level  functional  test.  Each  module 
was  built  and  tested  to  operate  at  clock  rate  of  40  MHz  for  the  ADSP21060  DSPs. 

2.4.L2  PROBLEMS 

No  problems  of  significance  were  encountered  that  needs  further  reporting. 

2.4.1.3  NOTES 

None. 

2.4.1 .4  LESSON  LEARN 

2.4.1. 4.1  _ BUY  AVAILABLE  PARTS  THAT  MEET  SPECIFICATION  OF  DESIGN 

The  APU  modules  used  a  CQFP  package,  heat  slug  down  from  Analog  Devices.  A  thermal 
analysis  study  was  presented  and  s.ho\v^  '  a  program  meeting,  that  the  lesser  grade  PQFP 
commercial  parts  with  heat  slug  up  would  have  performed  within  specification  in  the  system. 

The  CQFP  parts  slipped  in  delivery  by  5  months  as  per  promised  date  from  Analog  Devices. 
These  parts  cost  an  additional  $90,000  (qty=220  pieces)  verses  the  PQFP  parts.  The  slippage  of 
delivery  had  a  cost  impact  on  the  program  on  both  software  and  hardware  resources.  The 
hardware  lost  labor  estimate  for  the  slippage  is  at  $40,000  minimally. 

2.4.2  BACK  PLANE  MODULES 

2.4.2.1  BUILT 

2  back  plane  modules  were  built  and  tested. 

2.4.2.2  PROBLEMS 

A  ground  loop  between  the  SUN  workstation  Myrinet  card  and  the  back  plane  unit  cause  bit  hit 
problems  during  testing.  With  the  proper  grounding  scheme,  this  issue  was  fully  corrected  to  the 
available  test  software’s  (Sunbug)  ability  to  detect  errors.  A  more  robust  test  scheme  needs  to  be 
implemented  to  lest  for  data  integrity  issues  of  the  Myrinet  network  to  determine  if  this  issue  still 
exists. 

Sunbug  test  software  has  a  limited  interface  to  change  the  data  test  patterns  and  packet  sizes  that 
are  sent  through  the  network.  Each  test  needed  the  software  to  be  recompiled  prior  to  executing. 
It  was  found  that  during  testing  that  various  patterns  and  data  set  sizes  would  cause  bit  errors  in 
the  network.  It  is  concluded  that  tests  need  to  be  expanded  to  a  greater  variety  of  data  patterns  and 
packet  sizes  to  lest  for  signal  integrity  issues. 

Sunbug  is  limited  to  a  “loop  back”  testing  scheme  through  the  port  switches.  Sunbug  does  not  test 
the  final  SAN  interface  to  the  LANai.  This  interface  was  tested  during  the  APU  modules  bench 
level  testing,  but  the  test  was  not  extended  to  the  system  level  test.  It  is  needed  during  system 
level  testing  to  verify  the  source  or  existence  of  any  signal  integrity  issues  on  the  Myrinet  network 
that  might  exist.  Test  software  needs  to  be  extended  from  a  PC  based  bench  software  to  a  SUN 
based  test  suite  of  software  that  tests  this  interface  on  a  per  node  basis.  Also,  this  test  software 
needs  to  exercise  various  data  patterns  and  packet  sizes  as  indicated  earlier  in  this  section. 

2.4.2.3  NOTES 

The  lack  of  a  more  robust  test  suite  for  the  back  plane  leaves  open  the  issue  that  signal  integrity 
problems  might  still  exist  with  the  back  plane  unit. 
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2.4.3  POWER  SYSTEM 


2.4.3.1  BUILT 

One  afl  shell  power  system  was  built.  The  system  converts  300  VDC  to  3.3  VDC  and  1 .2  VDC  to 
be  used  in  the  embedded  applications.  The  system  was  tested  and  is  functionally  working  as  a 
stand-alone. 

2.4.3.2  PROBLEMS 

No  problems  of  significance  were  encountered  that  needs  further  reporting. 

2.4.3.3  NOTE 

Since  system  integration  and  test  did  not  extend  far  from  bench  testing  utilizing  lab  supplies  and 
not  the  UUVSP  developed  power  system,  no  significance  utilization  of  the  power  system 
occurred.  Possible  problems  might  arise  if  further  integration  activity  occurred. 

2.4.4  MONITOR  BOX 

2.4.4.1  BUILT 

One  monitor  box  system  was  built.  The  system  was  tested  and  is  functionally  working  with  the 
power  system,  but  not  as  an  integrated  unit  with  the  APU  modules  due  to  the  extent  of  process  during 
system  integration  and  test. 

2.4.4.2  PROBLEMS 

No  problems  of  significance  were  encountered  that  needs  further  reporting. 

2.4.4.3  NOTE 

Since  system  integration  and  test  did  not  extend  far  from  bench  testing  to  utilize  the  UUVSP 
monitor  box  unit,  possible  problems  might  arise  if  further  integration  activity  occurred. 

2.5.  SYSTEM  STATUS 

2.5.1  BUILT 

One  system  based  on  13  APU  modules. 

2.5.1.1  PROBLEMS 

Problems  during  system  integration  and  test  could  not  be  corrected  with  the  remaining  budget  on 
the  UUVSP  program. 

2.5. 1.1.1  SYSTEM  INTERGRATION  AND  TEST  PLAN 

The  integration  and  test  effort  executed  did  not  lend  itself  useful  to  a  debug  effort  that  could 
localize  faults  in  the  hardware  (or  software).  System  integration  and  test  used  a  scaled  down 
operational  algorithm  to  run  across  2.5  modules  (20  processors).  There  was  no  attempt  to  run  a 
program  BIT  on  the  modules  in  the  system  to  determine  a  module’s  health  prior  to  jumping  to 
testing  an  operational  algorithm  over  twenty  processor  units. 

2,5JJ^2___TEST  SOFTWARE 

The  HPSC  APU  module  SUN  based  level  test  software  was  never  utilized  for  the  UUVSP  system. 
It  would  have  been  helpful  in  accessing  and  localizing  faults  in  the  system.  The  SUN  based 
software  from  the  HPSC  effort  should  be  the  first  step  in  the  system  test  and  integration  phase  if 
this  program  is  extended.  This  software  would  be  most  helpful  in  localizing  faults  in  the  hardware 
and/or  software. 
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3. 


ALGORITHM  AND  SOFTWARE  DEVELOPMENT  (CDRL  A009) 


The  UUV  software  development  environment  was  SUN  Workstations,  and  Personal  Computer  (PC) 
Windows  3.1, 95(for  the  bootstrap  loader).  ADI  software  development  software  (hosted  on  the  SUN,  and 
the  PC)  was  used  to  develop  the  SHARC  software.  Wideband  Computers  Inc.  ADSP-21K  Optimized  DSP 
Library  was  used  to  provide  the  hand  optimized  functions  needed  in  the  bathymetric  algorithm. 

The  UUV  software  content  consisted  of: 

•  Bathymetric  Processing  Unit  (BPU)  software 

•  Interface  Unit  (lU)  Software 

•  Operator  Console  (SUN  SPARC  Station),  with  the  SUN  support  software. 

•  Common  to  the  BPU  and  the  lU  was  the  Bootstrap  Loader,  and  support  tools  modifications  (this 
software  is  PC  based). 

•  Common  to  the  BPU,  lU,  and  the  SUN  station  were  the  LANAI  Distributed  Architecture  Resource 
Controller  (DARC)  modifications. 

The  UUV  software  system  first  loads  each  processor  in  each  node  with  the  operator-specified  software. 
This  includes  the  4  lU  nodes,  and  up  to  48  BPU  nodes.  The  operator  then  specifies  configuration  data, 
sample  data,  and  operating  mode.  The  SUN  bascu  software  formats  the  selected  data  into  messages  that 
were  transmitted  to  the  lU.  The  lU  then  disseminates  this  information  to  the  BPU’s.  The  results  of  the 
BPU’s  are  transmitted  to  the  lU,  where  the  magnitudes  of  each  angular  bin  of  each  azimuth  angle  compare 
from  each  BPU  (48  -  1  data  reduction).  This  result  is  transmitted  to  the  operator  console. 

Figure  1  shows  how  the  information  was  disseminated  amongst  the  various  software  elements  during 
bathymetric  operations. 


Figure  1-  Software  Breakdown 
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3.1  UUV  Interface  Unit  (lU)  Software 

The  lU  performs  3  function  the  UUV  system.  First  it  provides  the  environmental  control  for  power 
management  and  leak  detection.  Second  it  simulates  the  sensor  front  end.  Third,  the  lU  acts  as  the  output 
unit  to  reduce  the  peak  results  collected  from  each  BPU  to  a  reportable  peak  results  (a  48  -  I  data 
reduction). 

To  achieve  the  environmental  control  the  lU  software  initializes  serial  port  0,  node  I,  processor  I 
Using  serial  port  0  it  can  read  192  potential  temperature  sensors,  control  the  secondary  power  converters 
supplying  power  the  BPU's,  HRA’s,  and  DACU’s.  It  is  capable  of  resetting  the  APU’s  and  the  DACU’s.  It 
can  also  check  the  status  of  the  power  system.  The  control  of  this  function  is  message  driven  under 
operator  command,  with  the  results  being  transmitted  as  a  message  back  to  the  operator  to  be  displayed  on 
the  operator  console.  Because  of  hardware  limitations  affecting  the  serial  port,  this  function  couldn  t  be 
fully  tested. 

To  simulate  the  sensor  front  end  the  lU  used  nodes  2  and  4.  This  was  chosen  because  of  the  Myrinet 
connectivity,  thus  minimizing  routing  conflicts.  The  “Input  Nodes”  each  were  responsible  for  transmitting 
the  sample  data  to  of  the  configured  BPU’s.  A  timer  was  used  to  simulate  the  sampling  rate  ( 10875  Hz) 
of  the  sensor  front  end.  The  software  would  DMA  the  sample  data  from  the  input  queue  (in  DRAM),  into 
SHARC  SRAM,  then  DMA  the  sample  data  to  the  output  queue(also  in  DRAM).  When  the  timer  event 
occurred,  the  transmit  command  would  occur.  This  software  had  to  keep  track  of  the  number  of  frames 
sent  and  determine  when  to  set  the  end  of  ping  flag  in  the  sample  data  message.  The  Input  nodes  had  to 
have  a  flow  control  for  when  the  UUV  system  was  the  continuous  operation  mode.  This  was  necessitated 
because  the  BPU’s  took  -  2  seconds  to  process  a  1  second  ping.  This  required  the  output  node  to  send  a 
message  via  Myrinet  to  the  2  input  nodes  once  the  lU  output  node  had  received  the  peak  results  from  the  all 
of  the  BPU’s.  The  flow  control  for  continuous  processing  was  implemented,  but  not  tested. 

The  third  function  that  the  lU  performed  was  to  reduce  the  results  produced  from  the  48  BPU's  to  1 
reportable  result,  a  48  to  1  reduction  of  data.  The  3'"^  node  of  the  lU  performed  this  function  using  all  4 
processors.  After  reduction,  the  results  were  transmitted  to  the  SUN  operator  console  for 
storage/comparison/display. 


3.2.  UUV  Bootstrap  Loader/Tools  Software 

The  UUV  bootstrap  loader  was  designed  primarily  under  HPSC.  Modifications  had  to  be  done  to  boot 
without  the  use  of  the  “Root  Node”,  and  to  the  Prom  loader  routine  due  to  the  changes  to  the  link  port 
connectivity.  This  required  changing  the  support  tools  associated  with  the  bootstrap  loader.  These  support 
tools  were  used  to  burn  the  bootstrap  loader  into  the  flash  ROM. 

3.3  UUV  Bathymetric  Software 

The  bathymetric  software  responds  to  3  type  of  messages  received: 

•  Initial  Parameters  Message 

•  Sample  Data  messages 

•  DAP  Header  messages 

And  transmitted  to  the  lU  output  node,  the  results  of  the  bathymetric  algorithm  in  the  peak  results  message 

The  initial  parameter  message  initializes: 

•  the  number  of  BPU  nodes 

•  the  frame  frequency 

•  the  number  of  angular  bins 

•  the  azimuth  start  angle 

•  the  azimuth  angle  increment 

•  the  number  of  azimuth  angles  (This  must  be  a  multiple  of  4) 

•  speed  of  sound 

•  array  element  spacing 
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•  sensor  gain 


The  initial  parameter  message  would  be  received  once  with  the  above  parameters.  The  software  would  use 
these  parameters  to  allocate  memory  buffers,  and  initialize  parameters  needed  in  the  bathymetric  algorithm. 
This  message  should  not  be  used  in  real  time,  since  data  buffers  are  deallocated  and  reallocated. 

The  DAP  header  message  initializes: 

•  number  of  frames  per  ping 

•  receive  gate  delay 

•  the  D/A  trigger  delay 

•  the  transmit  frequency 

•  the  decimation  rate 

•  the  time  vs.  gain  table 

The  DAP  header  parameters  were  created  when  the  sample  data  was  collected.  Some  of  these  parameters 
are  used  to  allocate  data  buffers,  and  to  initialize  parameters  needed  in  the  bathymetric  algorithm.  As  in 
the  initial  parameter  message,  this  message  is  not  intended  for  real  time.  If  the  system  selected  was  single 
ping  mode,  the  DAP  header  message  would  be  sent  out  for  every  sample  sent.  If  the  system  was  in 
continuous  mode,  the  DAP  header  message  would  only  be  sent  once.  It  would  be  assumed  that  to  change 
the  DAP  parameters  would  require  a  change  to  the  DAP  mode,  thus  stopping  sample  operations  while  this 
change  was  in  progress. 

The  Sample  Data  message  contains 

•  end  of  ping  flag 

•  512  packed  16  bit  integer  In-phase  and  Quadrature  (I,Q)  pairs  (i.e.  1  frame  of  sample  data) 

Each  ping  contains  10875  (default  value)  frames  of  sample  data.  The  default  number  of  BPU’s  is  48,  thus 
each  BPU  processes  -227  frames  of  data.  The  detection  of  end  of  ping  flag  in  the  sample  data  message 
caused  the  transmission  of  the  Peak  results  message  to  the  lU.  Each  frame  calculation  would  compare  the 
magnitude  calculated  with  the  previous  maximum  magnitude  for  that  azimuth  and  angular  bin,  saving  the 
greater  magnitude,  with  the  associated  frame  and  angle. 

The  Peak  Results  Message  transmitted  from  the  BPU  to  the  lU  contains  [number  of  azimuths][number  of 
angular  bins]  -  the  number  of  azimuths  (40  default),  and  the  number  of  angular  bins  (255  default). 

•  frame  data 

•  angle 

•  magnitude 

Timings  were  done  on  the  bathymetric  algorithm  using  4  nodes,  and  the  HPSC  APU's.  Expand  this  timing 
to  48  UUV  APU  nodes,  with  the  currently  implemented  bathymetric  algorithm,  a  1  second  ping  would  be 
processed  in  -1.97  -2.0  seconds. 


3.4.  UUV  Operator  Console  Software 

The  SUN  based  operator  console  provided  a  Graphical  User  Interface  (GUI)  (designed  using  X  Designer) 
which  the  operator  could  control  the  operation  of  the  UUV  system.  The  GUI  selected/sent  the  initialization 
parameters,  the  DAP  header  parameters,  and  the  sample  data.  The  operator  could  also  request/view  the 
UUV  temperature  status,  the  power  status,  and  select  the  operating  mode  (Single  Ping/Conlinuous 
operation).  The  GUI  also  downloaded  the  UUV  software  to  the  lU,  BPU’s,  and  LANai’s.  The  SUN 
softvvare  was  also  able  to  read  network  configuration  files  to  be  able  to  generation  the  routing  parameter 
tables,  and  the  message  parameter  tables  for  the  UUV  system. 


3.5.  LANAI  Distributed  Architecture  Resource  Controller  (DARC)  modifications 

The  DARC  was  originally  implemented  using  256K  32bit  words  of  SRAM.  In  the  UUV  design,  only  128K 
32bit  words  of  SRAM  were  used.  This  required  that  the  DARC  have  modifications  done  so  that  memory- 
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mapped  variables  could  have  their  addresses  change.  The  decision  was  made  to  use  a  configuration  header 
flic  that  defined  all  the  addresses  of  importance.  This  then  allowed  all  future  customers  that  ability  to 
customize  their  memory  requirements.  This  proved  usefully  when  the  SBUS  card  in  the  SUN  station 
providing  the  25M  Myrinet  communicated  was  upgraded  from  128K  bytes  to  a  512K  bytes.  The  same 
configuration  file  was  used  in  the  SUN  DARC  thus  requiring  only  minor  changes. 


3.6.  Lessons  Learned 

Porting  the  bathymetric  algorithm  was  the  trivial  part  of  the  software  job.  Controlling  the  data  messages  is 
the  key  to  scaleable  computing.  For  sensor  applications,  the  communication  protocol  must  be  able  to  send 
data  continuously  with  minimal  overhead.  At  the  start  of  software  development,  the  only  available  Myrinet 
Control  Program  (MCP)  was  the  Data  Synchronization  Queue  (DSQ).  For  this  reason,  DSQ’s  were  used  in 
the  UUV  software.  A  lesson  learned  was  not  to  rely  on  immature  technology.  The  MCP  used  was  not  a 
mature  technology.  The  personnel  responsible  for  this  technology  had  persuaded  other  professional 
opportunities.  The  above,  was  also  true  of  the  bootstrap  loader/tools  software.  This  required  the  UUV 
software  team  to  spend  time  debugging/iearning  these  technologies.  It  should  also  be  noted  that  because 
these  technologies  are  leading  edge/immalure,  the  tools  needed  to  debug  them  are  immature. 

The  Total  View  debugger  was  used  to  debug  the  SHARC  based  software.  This  made  possible  debugging 
multiple  SHARCs,  on  multiple  nodes  in  real  time.  This  was  a  significant  improvement  over  existing 
debuggers.  The  Total  View  operated  on  a  Sun  workstation  with  the  25M  SBUS  Myrinet  card.  It  used  the 
HPSC  DARC  for  its  MCP.  This  tool,  though  immature,  greatly  enhanced  the  ability  to  debug  scaleable 
computing  solutions  on  the  SHARC. 

The  Math  library  used  on  UUV  was  Wideband  Computers  Inc.  ADSP-2IK  Optimized  DSP  Library.  It’s 
$1500.00  price  tag,  with  no  run-time  licensing  fee  is  good.  The  company  gives  excellent  service  after  the 
sale  without  hassles.  This  library  performed  well  for  the  UUV  project. 

The  ADI  software  development  tools  (3. 2/3. 3)  are  poor.  The  compiler  has  bugs.  The  linker/simulator 
(3.2/3.3)  doesn’t  support  the  multiprocessor  memory  space.  The  prom  loader  (3.2)  only  worked  for 
processor  ID  0,  (the  Root  Node  for  HPSC  APU’s.  UUV  APU’s  don’t  have  a  root  node).  This  requires 
UUV  personnel  to  debug  ADI’s  software.  This  then  required  UUV  to  upgrade  to  version  3.3.  ADI  has 
released  (OI-JumQS),  for  the  PC,  Visual  DSP. 

The  biggest  problem  affecting  UUV  software  was  the  inability  to  transmit  and  receive  sample  data  reliable. 
Data  packets  would  become  corrupt,  get  dropped,  thus  preventing  the  system  from  operating.  More  effort 
is  needed  to  develop  testing  methods  to  identify  potential  hardware/software  problems  associated  with 
large-scale  data  movement. 
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